home *** CD-ROM | disk | FTP | other *** search
/ Personal Computer World 2005 October / PCWOCT05.iso / Software / FromTheMag / XAMPP 1.4.14 / xampp-win32-1.4.14-installer.exe / xampp / php / extras / mibs / SNMP-FRAMEWORK-MIB.txt < prev    next >
Text File  |  2005-03-30  |  21KB  |  498 lines

  1. SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
  2.  
  3. IMPORTS
  4.     MODULE-IDENTITY, OBJECT-TYPE,
  5.     OBJECT-IDENTITY,
  6.     snmpModules                           FROM SNMPv2-SMI
  7.     TEXTUAL-CONVENTION                    FROM SNMPv2-TC
  8.     MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF;
  9.  
  10. snmpFrameworkMIB MODULE-IDENTITY
  11.     LAST-UPDATED "9901190000Z"            -- 19 January 1999
  12.     ORGANIZATION "SNMPv3 Working Group"
  13.     CONTACT-INFO "WG-EMail:   snmpv3@tis.com
  14.                   Subscribe:  majordomo@tis.com
  15.                               In message body:  subscribe snmpv3
  16.  
  17.                   Chair:      Russ Mundy
  18.                               TIS Labs at Network Associates
  19.                   postal:     3060 Washington Rd
  20.                               Glenwood MD 21738
  21.                               USA
  22.                   EMail:      mundy@tis.com
  23.                   phone:      +1 301-854-6889
  24.  
  25.                   Co-editor   Dave Harrington
  26.                               Cabletron Systems, Inc.
  27.                   postal:     Post Office Box 5005
  28.                               Mail Stop: Durham
  29.                               35 Industrial Way
  30.                               Rochester, NH 03867-5005
  31.                               USA
  32.                   EMail:      dbh@ctron.com
  33.                   phone:      +1 603-337-7357
  34.  
  35.                   Co-editor   Randy Presuhn
  36.                               BMC Software, Inc.
  37.                   postal:     965 Stewart Drive
  38.                               Sunnyvale, CA 94086
  39.                               USA
  40.                   EMail:      randy_presuhn@bmc.com
  41.                   phone:      +1 408-616-3100
  42.  
  43.                   Co-editor:  Bert Wijnen
  44.                               IBM T.J. Watson Research
  45.                   postal:     Schagen 33
  46.                               3461 GL Linschoten
  47.  
  48.                               Netherlands
  49.                   EMail:      wijnen@vnet.ibm.com
  50.                   phone:      +31 348-432-794
  51.                  "
  52.     DESCRIPTION  "The SNMP Management Architecture MIB"
  53. -- Revision History
  54.  
  55.     REVISION     "9901190000Z"            -- 19 January 1999
  56.     DESCRIPTION  "Updated editors' addresses, fixed typos.
  57.                   Published as RFC2571.
  58.                  "
  59.     REVISION     "9711200000Z"            -- 20 November 1997
  60.     DESCRIPTION  "The initial version, published in RFC 2271.
  61.                  "
  62.     ::= { snmpModules 10 }
  63.  
  64. -- Textual Conventions used in the SNMP Management Architecture ***
  65.  
  66. SnmpEngineID ::= TEXTUAL-CONVENTION
  67.     STATUS       current
  68.     DESCRIPTION "An SNMP engine's administratively-unique identifier.
  69.                  Objects of this type are for identification, not for
  70.                  addressing, even though it is possible that an
  71.                  address may have been used in the generation of
  72.                  a specific value.
  73.  
  74.                  The value for this object may not be all zeros or
  75.                  all 'ff'H or the empty (zero length) string.
  76.  
  77.                  The initial value for this object may be configured
  78.                  via an operator console entry or via an algorithmic
  79.                  function.  In the latter case, the following
  80.                  example algorithm is recommended.
  81.  
  82.                  In cases where there are multiple engines on the
  83.                  same system, the use of this algorithm is NOT
  84.                  appropriate, as it would result in all of those
  85.                  engines ending up with the same ID value.
  86.  
  87.                  1) The very first bit is used to indicate how the
  88.                     rest of the data is composed.
  89.  
  90.                     0 - as defined by enterprise using former methods
  91.                         that existed before SNMPv3. See item 2 below.
  92.  
  93.                     1 - as defined by this architecture, see item 3
  94.                         below.
  95.  
  96.                     Note that this allows existing uses of the
  97.                     engineID (also known as AgentID [RFC1910]) to
  98.                     co-exist with any new uses.
  99.  
  100.                  2) The snmpEngineID has a length of 12 octets.
  101.  
  102.                     The first four octets are set to the binary
  103.                     equivalent of the agent's SNMP management
  104.                     private enterprise number as assigned by the
  105.                     Internet Assigned Numbers Authority (IANA).
  106.                     For example, if Acme Networks has been assigned
  107.                     { enterprises 696 }, the first four octets would
  108.                     be assigned '000002b8'H.
  109.  
  110.                     The remaining eight octets are determined via
  111.                     one or more enterprise-specific methods. Such
  112.                     methods must be designed so as to maximize the
  113.                     possibility that the value of this object will
  114.                     be unique in the agent's administrative domain.
  115.                     For example, it may be the IP address of the SNMP
  116.                     entity, or the MAC address of one of the
  117.                     interfaces, with each address suitably padded
  118.                     with random octets.  If multiple methods are
  119.                     defined, then it is recommended that the first
  120.                     octet indicate the method being used and the
  121.                     remaining octets be a function of the method.
  122.  
  123.                  3) The length of the octet strings varies.
  124.  
  125.                     The first four octets are set to the binary
  126.                     equivalent of the agent's SNMP management
  127.                     private enterprise number as assigned by the
  128.                     Internet Assigned Numbers Authority (IANA).
  129.                     For example, if Acme Networks has been assigned
  130.                     { enterprises 696 }, the first four octets would
  131.                     be assigned '000002b8'H.
  132.  
  133.                     The very first bit is set to 1. For example, the
  134.                     above value for Acme Networks now changes to be
  135.                     '800002b8'H.
  136.  
  137.                     The fifth octet indicates how the rest (6th and
  138.                     following octets) are formatted. The values for
  139.                     the fifth octet are:
  140.  
  141.                       0     - reserved, unused.
  142.  
  143.                       1     - IPv4 address (4 octets)
  144.  
  145.                               lowest non-special IP address
  146.  
  147.                       2     - IPv6 address (16 octets)
  148.                               lowest non-special IP address
  149.  
  150.                       3     - MAC address (6 octets)
  151.                               lowest IEEE MAC address, canonical
  152.                               order
  153.  
  154.                       4     - Text, administratively assigned
  155.                               Maximum remaining length 27
  156.  
  157.                       5     - Octets, administratively assigned
  158.                               Maximum remaining length 27
  159.  
  160.                       6-127 - reserved, unused
  161.  
  162.                     127-255 - as defined by the enterprise
  163.                               Maximum remaining length 27
  164.                 "
  165.     SYNTAX       OCTET STRING (SIZE(5..32))
  166.  
  167. SnmpSecurityModel ::= TEXTUAL-CONVENTION
  168.     STATUS       current
  169.     DESCRIPTION "An identifier that uniquely identifies a
  170.                  securityModel of the Security Subsystem within the
  171.                  SNMP Management Architecture.
  172.  
  173.                  The values for securityModel are allocated as
  174.                  follows:
  175.  
  176.                  - The zero value is reserved.
  177.                  - Values between 1 and 255, inclusive, are reserved
  178.                    for standards-track Security Models and are
  179.                    managed by the Internet Assigned Numbers Authority
  180.                    (IANA).
  181.                  - Values greater than 255 are allocated to
  182.                    enterprise-specific Security Models.  An
  183.                    enterprise-specific securityModel value is defined
  184.                    to be:
  185.  
  186.                    enterpriseID * 256 + security model within
  187.                    enterprise
  188.  
  189.                    For example, the fourth Security Model defined by
  190.                    the enterprise whose enterpriseID is 1 would be
  191.                    260.
  192.  
  193.                  This scheme for allocation of securityModel
  194.                  values allows for a maximum of 255 standards-
  195.                  based Security Models, and for a maximum of
  196.                  255 Security Models per enterprise.
  197.  
  198.                  It is believed that the assignment of new
  199.                  securityModel values will be rare in practice
  200.                  because the larger the number of simultaneously
  201.                  utilized Security Models, the larger the
  202.                  chance that interoperability will suffer.
  203.                  Consequently, it is believed that such a range
  204.                  will be sufficient.  In the unlikely event that
  205.                  the standards committee finds this number to be
  206.                  insufficient over time, an enterprise number
  207.                  can be allocated to obtain an additional 255
  208.                  possible values.
  209.  
  210.                  Note that the most significant bit must be zero;
  211.                  hence, there are 23 bits allocated for various
  212.                  organizations to design and define non-standard
  213.                  securityModels.  This limits the ability to
  214.                  define new proprietary implementations of Security
  215.                  Models to the first 8,388,608 enterprises.
  216.  
  217.                  It is worthwhile to note that, in its encoded
  218.                  form, the securityModel value will normally
  219.                  require only a single byte since, in practice,
  220.                  the leftmost bits will be zero for most messages
  221.                  and sign extension is suppressed by the encoding
  222.                  rules.
  223.  
  224.                  As of this writing, there are several values
  225.                  of securityModel defined for use with SNMP or
  226.                  reserved for use with supporting MIB objects.
  227.                  They are as follows:
  228.  
  229.                      0  reserved for 'any'
  230.                      1  reserved for SNMPv1
  231.                      2  reserved for SNMPv2c
  232.                      3  User-Based Security Model (USM)
  233.                 "
  234.     SYNTAX       INTEGER(0 .. 2147483647)
  235.  
  236. SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
  237.     STATUS       current
  238.     DESCRIPTION "An identifier that uniquely identifies a Message
  239.                  Processing Model of the Message Processing
  240.                  Subsystem within a SNMP Management Architecture.
  241.  
  242.                  The values for messageProcessingModel are
  243.                  allocated as follows:
  244.  
  245.                  - Values between 0 and 255, inclusive, are
  246.                    reserved for standards-track Message Processing
  247.                    Models and are managed by the Internet Assigned
  248.                    Numbers Authority (IANA).
  249.  
  250.                  - Values greater than 255 are allocated to
  251.                    enterprise-specific Message Processing Models.
  252.                    An enterprise messageProcessingModel value is
  253.                    defined to be:
  254.  
  255.                    enterpriseID * 256 +
  256.                         messageProcessingModel within enterprise
  257.  
  258.                    For example, the fourth Message Processing Model
  259.                    defined by the enterprise whose enterpriseID
  260.                    is 1 would be 260.
  261.  
  262.                  This scheme for allocating messageProcessingModel
  263.                  values allows for a maximum of 255 standards-
  264.                  based Message Processing Models, and for a
  265.                  maximum of 255 Message Processing Models per
  266.                  enterprise.
  267.  
  268.                  It is believed that the assignment of new
  269.                  messageProcessingModel values will be rare
  270.                  in practice because the larger the number of
  271.                  simultaneously utilized Message Processing Models,
  272.                  the larger the chance that interoperability
  273.                  will suffer. It is believed that such a range
  274.                  will be sufficient.  In the unlikely event that
  275.                  the standards committee finds this number to be
  276.                  insufficient over time, an enterprise number
  277.                  can be allocated to obtain an additional 256
  278.                  possible values.
  279.  
  280.                  Note that the most significant bit must be zero;
  281.                  hence, there are 23 bits allocated for various
  282.                  organizations to design and define non-standard
  283.                  messageProcessingModels.  This limits the ability
  284.                  to define new proprietary implementations of
  285.                  Message Processing Models to the first 8,388,608
  286.                  enterprises.
  287.  
  288.                  It is worthwhile to note that, in its encoded
  289.                  form, the messageProcessingModel value will
  290.  
  291.                  normally require only a single byte since, in
  292.                  practice, the leftmost bits will be zero for
  293.                  most messages and sign extension is suppressed
  294.                  by the encoding rules.
  295.  
  296.                  As of this writing, there are several values of
  297.                  messageProcessingModel defined for use with SNMP.
  298.                  They are as follows:
  299.  
  300.                      0  reserved for SNMPv1
  301.                      1  reserved for SNMPv2c
  302.                      2  reserved for SNMPv2u and SNMPv2*
  303.                      3  reserved for SNMPv3
  304.                 "
  305.     SYNTAX       INTEGER(0 .. 2147483647)
  306.  
  307. SnmpSecurityLevel ::= TEXTUAL-CONVENTION
  308.     STATUS       current
  309.     DESCRIPTION "A Level of Security at which SNMP messages can be
  310.                  sent or with which operations are being processed;
  311.                  in particular, one of:
  312.  
  313.                    noAuthNoPriv - without authentication and
  314.                                   without privacy,
  315.                    authNoPriv   - with authentication but
  316.                                   without privacy,
  317.                    authPriv     - with authentication and
  318.                                   with privacy.
  319.  
  320.                  These three values are ordered such that
  321.                  noAuthNoPriv is less than authNoPriv and
  322.                  authNoPriv is less than authPriv.
  323.                 "
  324.     SYNTAX       INTEGER { noAuthNoPriv(1),
  325.                            authNoPriv(2),
  326.                            authPriv(3)
  327.                          }
  328.  
  329. SnmpAdminString ::= TEXTUAL-CONVENTION
  330.     DISPLAY-HINT "255a"
  331.     STATUS       current
  332.     DESCRIPTION "An octet string containing administrative
  333.                  information, preferably in human-readable form.
  334.  
  335.                  To facilitate internationalization, this
  336.                  information is represented using the ISO/IEC
  337.                  IS 10646-1 character set, encoded as an octet
  338.                  string using the UTF-8 transformation format
  339.  
  340.                  described in [RFC2279].
  341.  
  342.                  Since additional code points are added by
  343.                  amendments to the 10646 standard from time
  344.                  to time, implementations must be prepared to
  345.                  encounter any code point from 0x00000000 to
  346.                  0x7fffffff.  Byte sequences that do not
  347.                  correspond to the valid UTF-8 encoding of a
  348.                  code point or are outside this range are
  349.                  prohibited.
  350.  
  351.                  The use of control codes should be avoided.
  352.  
  353.                  When it is necessary to represent a newline,
  354.                  the control code sequence CR LF should be used.
  355.  
  356.                  The use of leading or trailing white space should
  357.                  be avoided.
  358.  
  359.                  For code points not directly supported by user
  360.                  interface hardware or software, an alternative
  361.                  means of entry and display, such as hexadecimal,
  362.                  may be provided.
  363.  
  364.                  For information encoded in 7-bit US-ASCII,
  365.                  the UTF-8 encoding is identical to the
  366.                  US-ASCII encoding.
  367.  
  368.                  UTF-8 may require multiple bytes to represent a
  369.                  single character / code point; thus the length
  370.                  of this object in octets may be different from
  371.                  the number of characters encoded.  Similarly,
  372.                  size constraints refer to the number of encoded
  373.                  octets, not the number of characters represented
  374.                  by an encoding.
  375.  
  376.                  Note that when this TC is used for an object that
  377.                  is used or envisioned to be used as an index, then
  378.                  a SIZE restriction MUST be specified so that the
  379.                  number of sub-identifiers for any object instance
  380.                  does not exceed the limit of 128, as defined by
  381.                  [RFC1905].
  382.  
  383.                  Note that the size of an SnmpAdminString object is
  384.                  measured in octets, not characters.
  385.                 "
  386.     SYNTAX       OCTET STRING (SIZE (0..255))
  387.  
  388. -- Administrative assignments ***************************************
  389.  
  390. snmpFrameworkAdmin
  391.     OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
  392. snmpFrameworkMIBObjects
  393.     OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
  394. snmpFrameworkMIBConformance
  395.     OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
  396.  
  397. -- the snmpEngine Group ********************************************
  398.  
  399. snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
  400.  
  401. snmpEngineID     OBJECT-TYPE
  402.     SYNTAX       SnmpEngineID
  403.     MAX-ACCESS   read-only
  404.     STATUS       current
  405.     DESCRIPTION "An SNMP engine's administratively-unique identifier.
  406.                 "
  407.     ::= { snmpEngine 1 }
  408.  
  409. snmpEngineBoots  OBJECT-TYPE
  410.     SYNTAX       INTEGER (1..2147483647)
  411.     MAX-ACCESS   read-only
  412.     STATUS       current
  413.     DESCRIPTION "The number of times that the SNMP engine has
  414.                  (re-)initialized itself since snmpEngineID
  415.                  was last configured.
  416.                 "
  417.     ::= { snmpEngine 2 }
  418.  
  419. snmpEngineTime   OBJECT-TYPE
  420.     SYNTAX       INTEGER (0..2147483647)
  421.     UNITS        "seconds"
  422.     MAX-ACCESS   read-only
  423.     STATUS       current
  424.     DESCRIPTION "The number of seconds since the value of
  425.                  the snmpEngineBoots object last changed.
  426.                  When incrementing this object's value would
  427.                  cause it to exceed its maximum,
  428.                  snmpEngineBoots is incremented as if a
  429.                  re-initialization had occurred, and this
  430.                  object's value consequently reverts to zero.
  431.                 "
  432.     ::= { snmpEngine 3 }
  433.  
  434. snmpEngineMaxMessageSize OBJECT-TYPE
  435.     SYNTAX       INTEGER (484..2147483647)
  436.     MAX-ACCESS   read-only
  437.     STATUS       current
  438.     DESCRIPTION "The maximum length in octets of an SNMP message
  439.                  which this SNMP engine can send or receive and
  440.                  process, determined as the minimum of the maximum
  441.                  message size values supported among all of the
  442.                  transports available to and supported by the engine.
  443.                 "
  444.     ::= { snmpEngine 4 }
  445.  
  446. -- Registration Points for Authentication and Privacy Protocols **
  447.  
  448. snmpAuthProtocols OBJECT-IDENTITY
  449.     STATUS        current
  450.     DESCRIPTION  "Registration point for standards-track
  451.                   authentication protocols used in SNMP Management
  452.                   Frameworks.
  453.                  "
  454.     ::= { snmpFrameworkAdmin 1 }
  455.  
  456. snmpPrivProtocols OBJECT-IDENTITY
  457.     STATUS        current
  458.     DESCRIPTION  "Registration point for standards-track privacy
  459.                   protocols used in SNMP Management Frameworks.
  460.                  "
  461.     ::= { snmpFrameworkAdmin 2 }
  462.  
  463. -- Conformance information ******************************************
  464.  
  465. snmpFrameworkMIBCompliances
  466.                OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
  467. snmpFrameworkMIBGroups
  468.                OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
  469.  
  470. -- compliance statements
  471.  
  472. snmpFrameworkMIBCompliance MODULE-COMPLIANCE
  473.     STATUS       current
  474.     DESCRIPTION "The compliance statement for SNMP engines which
  475.                  implement the SNMP Management Framework MIB.
  476.                 "
  477.     MODULE    -- this module
  478.         MANDATORY-GROUPS { snmpEngineGroup }
  479.     ::= { snmpFrameworkMIBCompliances 1 }
  480.  
  481. -- units of conformance
  482.  
  483. snmpEngineGroup OBJECT-GROUP
  484.     OBJECTS {
  485.               snmpEngineID,
  486.               snmpEngineBoots,
  487.               snmpEngineTime,
  488.               snmpEngineMaxMessageSize
  489.             }
  490.     STATUS       current
  491.     DESCRIPTION "A collection of objects for identifying and
  492.                  determining the configuration and current timeliness
  493.                  values of an SNMP engine.
  494.                 "
  495.     ::= { snmpFrameworkMIBGroups 1 }
  496.  
  497. END
  498.